The present invention relates to data caching, more specifically, to a data caching method and device and a resource request response method and device.
Data caching is the key to improve response time of massive data processing applications such as social network, cooperative network applications and so on. These applications produce two kinds of data, public data and private data. There are good solutions for public data caching. The most common ways for public data caching are: 1) setting up a public cacheable HTTP header in an HTTP (Hyper Text Transfer Protocol) response header for public resources such as public web pages, public files, etc., a caching server (e.g., a WebSphere Edge server from IBM) caching related content locally, and if the requested content is in its cache, the caching server returning the related content back to the user instead of sending a request to an application server; 2) moving public cachable content to a regional caching server (Content distribution Network or CDN) and routing the user request to the nearest caching server to get the best information. For private data, the most common approaches are: 1) not to allow caching; 2) setting up a private cachable header in the HTTP response, which means that the content can be cached by an end-user browser but not a caching server, so that the user privacy is guaranteed.
However, there is a third type of data in network applications. The access to such data is limited to only members of a specific user-group, and users out of the user-group are not permitted to access such data. For example, the user-group may be an online user group, a community, a team or the like, and the corresponding data may be Blogs, discussion on a forum, Wikipedia pages, files or the like. Public caching cannot be applied to this kind of data, since it may leak the data to the users out of the group. Meanwhile, processing the data by the private caching header cannot achieve a good performance due to that the cached data cannot be shared between members of the group; therefore it cannot further improve the systematic performance, especially for the groups having thousands of users.